Plasma processing systems have long employed to process wafers into end electronic products. In a typical plasma system, there typically exists a front end, also known as an Equipment Front End Module (EFEM). The front end module typically represents the module designed to receive wafers from a storage location or a buffer location and to facilitate loading of the wafers into one or more load locks to be eventually loaded into one or more processing chambers.
Generally speaking, the load locks represent the interface between the outside atmospheric environment and the in-chamber processing environment in which parameters (e.g., pressure, gas flow, RF power, RF bias, etc.) are carefully controlled in accordance with the processing recipe.
With reference to FIG. 1, for example, there is shown an example plasma processing system 100, including a front end module 104, a plurality of load locks 106A-106D, and a plurality of processing modules 110A-110F. Front end module 104, representing the aforementioned EFEM in this example, may interface with one or more load locks for receiving wafers, which may be sent to front end module 104 in a batch or one wafer at a time from a storage or buffer location. Front end module 104 may include hardware and logic for interfacing between the human user and/or host computer and the load locks, for example. Front end module 104 may also include hardware and software for transferring wafers between storage/buffer locations and the load locks to facilitate processing by the process modules or chambers.
Wafers 102 represent production wafers (i.e., wafers to be processed into the desired end products) in the example of FIG. 1. There may also exist maintenance wafers 108, representing wafers employed for chamber maintenance/clean purposes. For example, specialized wafers may be used to season the chamber or to prepare the chamber or to clean the chamber. Maintenance wafers 108 may be stored in a dedicated location, and a maintenance wafer may be employed once or multiple times before the end of its lifetime.
Front end module 104 receives one or more of wafers 102 or 108 (typically but not necessarily a single wafer at a time for a capacitively coupled plasma processing system) and loads the wafer into one of load locks 106A-106D. From one of load locks 106A-106D, the wafer is then transported into one of processing chambers or processing modules (PM) 110A-100H for processing. The transportation of wafers into load locks 106A-106D and from one of load locks 106A-106D into one of PM's 110A-100H (as well as the unloading therefrom) may be accomplished using a suitable transport mechanism such as a robot arm, for example.
For various reasons, including economic and non-economic reasons, customers of semiconductor processing equipment manufacturers have attempted to acquire the front end module independently from the rest of the semiconductor processing system, such as independently from the back end that includes one or more processing modules or processing chambers. Customers may be motivated to save cost by buying a commodity front end and developing software applications to suit their own needs. Furthermore, customers may have a desire to develop and retain in-house expertise pertaining to front end operation. Still further, customers may have proprietary information pertaining to the recipes and/or the wafers, and they may wish to keep such proprietary information confidential even from the semiconductor equipment manufacturers (such as back end equipment manufacturers). As such, there has been a push from customers to require semiconductor equipment manufacturers to provide the back end independently and to provide an appropriate interface for the back end to work with the customer's front end.
In one example approach, the customer desires to push wafer information, including wafer data, recipe data, and any configuration information from the front end to the back end to dictate when and how wafers are processed by the back end. In accordance with this methodology, front end module 104 of FIG. 1 acts as the master or the host client, and each of back end chambers 110A-110F acts as a slave or the host server. The host server (or slave) provides service in response to instructions from the front end (or master).
In accordance with this push methodology, the role of back end chambers 110A-110F is to receive wafers, wafer data, recipe data, and configuration data from front end module 104, to load the wafers into the chambers when the wafers are pushed to the back end by the front end, and to execute the recipe to process the wafers. While this methodology is capable of achieving the customer's desired goal of modularizing the front end from the back end and of permitting the customer to acquire and customize a commodity front end to their own specifications, there are disadvantages.
For example, a tremendous amount of intelligence and data capabilities have been built into the back end over the last few years to enable the tool to achieve just-in-time loading of specific wafers into specific load locks and/or specific chambers, to perform various chamber readiness tasks, to schedule system auto-clean/auto-maintenance (with or without the use of a maintenance wafer), and to actually perform such auto-clean/auto-maintenance tasks when needed. These and other capabilities allow the overall tool to operate more reliably and efficiently, and to improve yield and output while minimizing the cost of ownership.
To further elaborate on one aspect of the back end intelligence and data capabilities, some back end may be endowed with logic and data gathering capabilities to enable the back end to analyze data obtained from intelligent sensors, consumable parts states, auto-clean/auto-maintenance schedule, and/or other historical and/or statistical analysis, and/or the like, to implement the just-in-time transportation of wafers to/from the load locks and to/from the chambers. Proper just-in-time delivery ensures that wafers from the front end are not untimely delivered to the load locks or chambers.
For example, untimely delivery of wafers to the load locks represents inefficient utilization of load lock resource if a delivered wafer must sit in a load lock to wait for chamber availability. If the chamber is not ready to receive a particular wafer because it still needs time to prepare itself (such as performing temperature or pressure stabilization or to perform auto-maintenance/auto-clean), for example, the fact that the wafer is already loaded into a load lock means that such load lock is now inefficiently used and must remain idle until the wafer can be unloaded from that load lock into the chamber.
This is a particularly acute problem in a multi-job environment where there are fewer load locks than there are process modules and load lock availability is at a premium. The problem is made even more acute when certain load locks are usable only for certain wafers and/or certain processing modules. This is because in some cases, for example, a load lock employed for loading and unloading production etch wafers may be deemed to have been contaminated with etch byproducts, thereby rendering such a load lock incompatible for loading/unloading a maintenance wafer. As another example, a load lock employed for loading and unloading production etch wafers may need to be at a specific temperature. As such, other load locks not stabilized at the required temperature may not be used to load/unload these specific production etch wafers.
One possible solution is for back end equipment manufacturers to share data with front end developers to enable the front end developers to more efficiently integrate the front end with the back end. In many cases, however, it is not possible or desirable for a back end equipment manufacturer to share the back end intelligence and data capabilities with front end developers due to intellectual property concerns, misuse concerns, and integration complexity concerns. For example, back end manufacturers may be reluctant to share the know-how required to evaluate the chamber readiness condition, to evaluate the chamber's need for auto-clean and/or auto-maintenance, and/or to implement other back end capabilities since such intelligence and data capabilities tend to be highly proprietary and may represent a significant competitive advantage to be protected from public disclosure.
Even if back end equipment manufacturers wish to share this back end intelligence and data capabilities with front end developers, the integration of such back end intelligence and data into the front end (e.g., for scheduling purposes) would render the customization of the front end extremely complex and may require front end developers to acquire a level of expertise typically not possessed by scientists and engineers who are not familiar with the development of back end technologies. Such an approach would render the integration task unduly time consuming and expensive.